IBIS Macromodel Task Group Meeting date: 21 May 2019 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: * Ambrish Varma Ken Willis Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki * Ming Yan Stephen Slater Maziar Farahmand Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz * Mike LaBonte SPISim: * Wei-hsing Huang Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Arpad to forward Walter's comments on BIRD197.3 to the entire ATM. - Done. - Bob to update the latest BIRD197.3 draft with revision info corrections. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the May 14 meeting. Radek moved to approve the minutes. Bob seconded the motion. There were no objections. ------------- New Discussion: IBIS v7.0 parser developer questions: Bob wanted to review two questions posed by the parser developer to ensure the group agreed on the answers. (Note: BIRD188.1, included in IBIS 7.0, introduced Rx_GaussianNoise as the preferred synonym for Rx_Noise, and it also introduced Rx_UniformNoise). 1. Should the parser throw an error if Rx_Noise and Rx_GaussianNoise appear in the same .ami file? Bob noted that he thought the answer was yes. Radek agreed that it should be an error. Arpad noted that pg. 249 of IBIS 7.0 defines Rx_GaussianNoise as the recommended equivalent name for the Rx_Noise parameter. Ambrish noted that we could add a statement to the spec explicitly stating that they can't both appear in the same .ami file. Bob noted that this would be an editorial addition to 7.1. The group agreed the parser should throw an error. 2. Can Rx_GaussianNoise and Rx_UniformNoise appear in the same .ami file? Bob noted that he thought the answer was yes. They are independent parameters and can both appear. The group agreed. Mike L. noted that there is some parallel with the different jitter distribution parameters that are allowed to co-exist. Arpad noted that if we allow them to co-exist, perhaps the spec should say something about how they are combined. Michael M. noted that we are currently leaving the combination and budgeting up to the EDA tools. He said sometimes by including multiple parameters the model maker is making assumptions about how they should be added together. He suggested there should be some way for the model maker to state, "we are assuming the budgeting will be performed the following way..." He noted that the industry probably agrees pretty well on the way things should be combined. Arpad said that would end up in a BIRD. Bob noted confusion could exist because the two noise parameters currently each define an equation for determining the Output_wave(t). Ambrish wasn't sure the spec needed to address this, and he asked where it would end. Radek said we currently have two different formulas stating: Output_wave(t) = wave(t) + ... and we should specify how the parameters are combined if they both exist. Mike L. said it's important to give the model maker a way to be sure that they know how their different jitter and/or noise parameters will be combined. Arpad said he wasn't sure we needed to explain every detail about how they are additive, but we should certainly explain it if/when any of them are mutually exclusive. The group agreed that addressing the clarifications would require a BIRD, and that the parser currently does not need to do anything if both of these parameters are present in a given .ami file. BIRD197.3_draft_4(DC_Offset): Arpad asked for further comments and discussion and asked if this was almost ready to send to the Open Forum. Ambrish noted that he had several questions. He noted that the waveform input to Rx GetWave() is centered about zero. Now with the new language, the model is supposed to add the DC offset back in to the output waveform, and the EDA tool should not add anything to the output. Ambrish said he thought the language was too vague and wishy-washy. Item 2. in the Other Notes: says "It CAN have a non-zero DC component..." Fangyi noted that the first sentence of that section explicitly states that, "The Rx AMI_GetWave output waveform is the physical waveform at the Rx latch." Ambrish suggested we explicitly state that if the waveform at the Rx latch has a DC offset then the model must return a waveform with that DC offset. Fangyi said he had no objection to adding a statement to that effect. Walter objected to the latest language with respect to the waveform returned by Rx GetWave. He noted that when he and Ambrish first drafted the BIRD the entire point was to keep the waveforms passed in and out of AMI models differential. He noted that the waveforms would typically be differential about VrefDQ, which itself is usually the same value as the amplitude midpoint of the step response. He said the DC_Offset parameter was introduced because when the signal heads down the channel it goes through amplifiers, and even though it's centered about VrefDQ there could be saturation issues if the voltage amplitudes get large relative to VrefDQ. So, there are non-linear effects that the model maker may want to include for a DDR5 Rx, and DC_Offset enables them to do it. But having done that, the basic output of Rx GetWave() should be a differential waveform centered about zero. When the tool samples that waveform, anything below zero should be considered a zero, and anything above zero should be considered a one. Arpad noted that further discussion will obviously be needed. - Mike L.: Motion to adjourn. - Michael M.: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 28 May 2019 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives